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ABSTRACT 

GLYNPIR  is  a  programming  language  intended  to  facilitate  the 
setup  and  manipulation  of  generalized  pointer -linked  data  structures  on 
ILLIAC  IV.   It  is  intentionally  a  very  machine- dependent  language,  and, 
in  fact,  it  can  be  thought  of  as  a  high  level  assembly  language  which 
automatically  generates  code  to  load  operands,  evaluate  expressions,  set 
up  subroutine  calls,  etc.   As  such,  it  is  potentially  useful  to  anyone 
who  is  currently  writing  assembly  code  for  ILLIAC  IV. 

GLYPNIR  should  also  be  useful  for  the  implementation  of  higher 
level  languages  either  as  intermediate  object  code  or  as  a  source  code 
for  compilers.   In  fact,  GLYPNIR  was  originally  designed  to  serve  as  a 
base  language  for  high  level  list  processing  languages  which  were  to  be 
implemented  through  the  use  of  macro  and  procedure  statements. 
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INTRODUCTION 

GLYPNIR  is  a  programming  language  intended  to  facilitate  the 
setup  and  manipulation  of  generalized  pointer-linked  data  structures  on 
ILLIAC  IV.   It  is  intentionally  a  very  machine-dependent  language,  and, 
in  fact,  it  can  be  thought  of  as  a  high  level  assembly  language  which 
automatically  generates  code  to  load  operands,  evaluate  expressions,  set 
up  subroutine  calls,  etc.  As  such,  it  is  potentially  useful  to  anyone 
who  is  currently  writing  assembly  code  for  ILLIAC  IV. 

GLYPNIR  should  also  be  useful  for  the  implementation  of  higher 
level  languages  either  as  intermediate  object  code  or  as  a  source  code 
for  compilers.   In  fact,  GLYPNIR  was  originally  designed  to  serve  as  a 
base  language  for  high  level  list  processing  languages  which  were  to  be 
implemented  through  the  use  of  macro  and  procedure  statements. 

This  manual  is  intended  to  serve  as  both  an  introduction  to 
GLYPNIR  and  a  user's  manual  for  Version  I.  The  following  chapters  des- 
cribe, both  formally  and  informally,  the  facilities  which  will  be  avail- 
able in  the  Version  I  compiler. 

The  syntax  of  GLYPNIR  has  been  designed  to  resemble  ALGOL  wherever 
possible,  and  the  reader  is  assumed  to  have  a  basic  knowledge  of  ALGOL. 
Additionally,  it  would  be  helpful  to  be  familiar  with  the  ILLIAC  IV  computer. 


1.   DESIGN  AND  IMPLEMENTATION 

GLYPNIR  is  a  list  processing  language  for  the  ILLIAC  IV 
computer  [1].   It  is  evident  that  "list  processing"  is  a  difficult  term 
to  define,  especially  with  relation  to  ILLIAC  IV.  For  the  purposes  of 
this  paper,  we  shall  define  list  processing  as  any  computation  which  is 
not  primarily  array  oriented,  that  is,  computations  characterized  by  data 
structures  which  are  not  wholly  arrays.   Studies  into  several  proposed 
applications  [2-5]  as  well  as  the  possibility  of  compiling  and  display 
processing  on  ILLIAC  IV  indicate  the  desirability  for  such  list  processing 
facilities. 

1.1  Design  Objectives 

GLYPNIR  has  been  designed  in  an  attempt  to  satisfy  several 
requirements  which  the  author  feels  are  necessary  in  a  list  processing 
language  for  ILLIAC  IV. 

(l)  The  language  should  restrict  the  data  structure  as 
little  as  possible.   Certain  structures  such  as 
vectors  and  pointers  should  be  inherent  in  the 
language,  but  the  user  should  be  able  to  combine 
and  link  his  data  in  any  way  which  will  facilitate 
the  calculation  in  which  he  is  interested. 
This  requirement  has  been  met  to  a  large  degree  by  using  the 
concept  of  programmer  defined  fields,  similar  to  those  employed  in  L  [6]. 
The  programmer  defines  the  placement,  size,  and  meaning  of  fields  within 
data  blocks,  and  thus  the  data  structure  can  (must)  be  designed  entirely 


by  the  programmer.  This,  of  course,  requires  a  certain  amount  of  tedious 
work  on  the  part  of  the  programmer  who  expects  to  find  his  data  structure 
designed  for  him.   However,  this  is  advantageous  in  that  the  programmer 
will  not  have  to  fit  his  data  into  some  pre-ordained  structure,  and  the 
resulting  organization  is  more  likely  to  allow  efficient  computation  and 
clearer  program  logic. 

(2)  The  language  should  be  extendable  and  modifiable  in 
the  sense  that  a  user  should  be  able  to  adapt  the 
language  to  the  point  where  the  routine  operations 
of  his  application  require  little  effort  in  program- 
ming or  thought. 

To  a  very  small  degree  this  requirement  has  been  satisfied  in  that  it  is 
easy  to  introduce  new  operators  into  GLYPNIR  at  the  compiler  level  and, 
through  the  use  of  the  translator  writing  system  [7]>  it  is  relatively 
easy  to  change  the  language  syntactically.   However,  it  is  obvious  that 
a  great  deal  more  work  needs  to  be  done  in  this  area.   Plans  are  underway 
to  include  macro  facilities  in  the  language  as  well  as  the  ability  to 
introduce  new  operators  at  the  source  program  level.  Further  study  of 
this  problem  is  being  directed  along  the  lines  of  Garwich  [8],  Leroy  [9]> 
and  Barron,  et_al.  [10]. 

(3)  The  programmer  should  be  able  to  communicate  closely 
with  the  machine.  This  would  allow  optimization  of 
routines  where  execution  speed  is  critical  and  to 


-* 
Even  the  very  simple  macro  facilities  embodied  in  the  <define 
declaration>  of  Burroughs  Extended  Algol  proved  to  be  extremely  useful 
in  the  implementation  of  the  GLYPNIR  compiler. 


utilize  special  hardware  features.   On  the  other 
hand,  the  programmer  should  not  need  to  worry  about 
routine  chores;  i.e.,  operations  like  common  data 
type  conversion,  expression  evaluation,  stack,  and 
mode  control,  pointer  chasing,  and  partial  word 
masking  should  be  done  automatically  by  the  system. 
The  functions  mentioned  above  are  performed  automatically  by  the  GLYPNIR 
compiler.   However,  the  programmer  may  override  these  functions  if  he  feels 
it  desirable  to  do  so.   For  example,  it  is  possible  to  write  a  statement 
such  as 

X  :=  (PNT.A  +  PNT.B)  X  C  +  PNT.A 

However,  if  this  statement  is  to  be  executed  many  times,  then  it  might  be 
desirable  to  optimize  it.   This  is  accomplished  by  the  following  sequence  : 

RGX  :=  PNT; 

RGS  :=  RGX. A; 

RGA  :=  RGX.B; 

X  :=  (RGA  +  RGS)  X  C  +  RGS 

This  sequence  will  result  in  the  generation  of  better  code  than  the  previous 


* 
The  terms  PNT.A  and  PNT.B  are  examples  of  one  of  the  basic  methods 
of  specifying  operands  in  GLYPNIR.   PNT.A  specifies  the  data  in  the  field 
A  of  the  block  pointed  to  by  the  variable  PNT.   Such  a  pointer  chain,  or 
field  content  designator  (FCD)  as  they  are  called  here,  can  be  arbitrarily 
long.  FCD's  are  treated  in  more  detail  in  the  following  chapters. 

*-* 

RGA,  RGS,  and  RGX  are  the  names  of  actual  hardware  registers 
in  ILLIAC  IV.   The  use  of  these  and  related  facilities  will  be  explained 
in  a  separate  document. 


statement  in  that  it  eliminates  two  fetches  or  I  "NT  and 

one  fetch  and  mask  of  the  contents  of  the  field  A. 

In  summary,  GLYPNIR  should  be  of  use  to  those  who  are  interested 
in  list  processing  and  to  those  who  want  a  language  which  is  easier  to  use 
than  assembly  language,  but  who  want  to  avoid  the  inefficiencies  of  a  higher 
level  language. 

1.2  Implementation 

GLYPNIR  has  been  implemented  with  a  one  pass  compiler  which 
utilizes  the  University  of  Illinois  Translator  Writing  System  [7].  The 
compiler  consists  of  approximately  9000  source  cards  and  was  written  in 
Burroughs  Extended  Algol  for  the  B5500  computer.  The  current  core  estimate 
is  approximately  12K  words  and  programs  are  compiled  at  300-400  cards  per 
minute.   Output  from  the  compiler  is  ILLIAC  IV  assembly  language.  Figure 
1  is  a  flow  diagram  showing  the  major  steps  required  in  the  translation  of 
a  GLYPNIR  program. 

The  compiler  can  be  logically  divided  into  three  sections:   the 
scanner,  the  parser,  and  the  translator.  A  brief  description  of  each  of 
these  follows. 

1.2.1  The  TWS  Scanner 

The  primary  purpose  of  the  scanner  is  to  interface  between  the 
user's  program  and  the  parser  and  translator.  The  scanner  converts 


Now  that  the  speed  and  size  of  the  compiler  are  known,  the  author 
readily  admits  that  efforts  should  have  been  directed  toward  a  two  pass 
compiler  which  would  improve  throughput  by  providing  for  syntax  debugging 
in  the  first  pass  and  postpone  actual  translation  until  the  second  pass. 
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Figure  1.  Flow  diagram  showing  the  major  steps 

required  to  translate  a  GLYPNIR  program. 


identifiers  and  special  symbols  into  an  internal  representation 
constructs  the  primary  identifier  table  (BIGTAB) .   It  is  essentially  the 
same  scanner  used  by  all  high  level  ILLIAC  IV  languages. 

1.2.2  The  TWST  Parser 

The  parser  used  in  Version  I  is  a  table  driven  recursive  descent 
parser  [7].   The  tables  were  generated  by  the  TWST  compiler  generator  pro- 
gram from  the  syntax  specifications  for  GLYPNIR  (see  Appendix  A).  The  pur- 
pose of  the  parser  is  to  recognize  certain  syntactic  constructs  in  the  user's 
program  and  call  appropriate  translator  routines  for  semantic  action. 

1.2.3  The  GLYPNIR  Translator 

The  GLYPNIR  translator  performs  the  actual  translation  from 
recognized  syntactic  entities  to  ILLIAC  IV  assembly  language.   It  would  be 
impossible  to  present  a  comprehensive  description  of  this  part  of  the  com- 
piler in  this  paper.  We  will  only  attempt  a  brief  overview  of  the  main 
tables  and  operand  control  structures. 

1.2.3.1  The  Identifier  Table 

.  The  main  data  table  is  LDTAB.   IDTAB  contains  information  which 
tells  what  each  identifier  represents  as  well  as  various  parameters  asso- 
ciated  with  the  identifier  and  possible  links  to  secondary  tables.   Figure 
2  shows  the  bounds  and  use  of  each  field  in  IDTAB.  Notice  that  each  entry 
in  IDTAB  consists  of  two  words.  The  format  for  the  first  word  is  the  same 


PADLAR,  the  subroutine  PArameter  Discriptor  ARray,  is  one  such 
secondary  table. 


for  all  entries  although  some  fields  are  not  used  for  some  identifiers. 
The  format  for  the  second  word  depends  on  what  the  identifier  represents. 

1.2.3*2  The  Main  Stack  and  Operand  Descriptors 

When  the  parser  recognizes  an  identifier  which  corresponds  to 
an  operand,  it  places  a  pointer  to  BIGTAB  in  the  main  stack  (MSTACK). 
BIGTAB  contains  a  further  pointer  to  IDTAB  where  information  about  the 
identifier  can  be  found.   Control  then  passes  to  the  translator  where  the 
information  in  IDTAB  is  used  to  construct  an  operand  descriptor  which  is 
then  placed  in  MSTACK.   The  format  for  this  descriptor  is  shown  in  Figure 
3.  After  the  descriptor  is  placed  in  MSTACK,  the  translator  may  generate 
ILLIAC  IV  assembly  code  -which  would  cause  the  operand  to  be  loaded  into 
an  ILLIAC  IV  register  or  to  be  operated  on  in  some  other  way.  Usually, 
the  MSTACK  descriptor  always  reflects  changes  in  the  status  of  an  operand 
which  will  have  been  caused  by  the  generated  assembly  code.   It  should  be 
kept  in  mind  that  these  descriptors  exist  in  the  compiler,  though  they 
describe  operands  which  will  exist  at  execution  time  on  ILLIAC  IV. 

1.2. 3*3  Operand  and  Hardware  Control  Structure 

As  mentioned  above,  when  code  is  generated  which  will  cause  an 
operand  to  be  loaded  into  a  hardware  register,  the  descriptor  for  this 
operator  in  MSTACK  is  modified  to  indicate  the  new  status  of  this  operand. 
If  we  wish  to  cause  another  operand  to  be  loaded  into  the  same  hardware 
register,  then  it  is  important  to  know  that  the  register  is  already  occupied 
and  by  which  operand  it  is  being  used.  This  knowledge  is  obtained  by  exam- 
ination of  the  hardware  control  structure. 
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For  each  ILLIAC  IV  hardware  register,  the  compiler  maintains 
a  link  word.   If  an  operand  is  currently  assumed  to  be  in  some  register, 
then  the  link  word  for  this  register  points  to  the  operand's  descriptor 
in  MSTACK.   (Otherwise  the  link  is  zero.)  Also,  the  operand's  descriptor 
implicitly  points  back  to  the  register  link  word.   For  example,  Figure  k 
shows  the  links  for  two  operands,  where  operand  A  is  assumed  to  be  in  RGA 
and  operand  B  is  assumed  to  be  in  PEM.   (These  links  exist  in  the  compiler, 
not  in  ILLIAC  IV. )  Figure  5  shows  the  condition  of  the  hardware  control 
structure  after  code  has  been  generated  to  move  operand  A  to  RGS  and  load 
operand  B  to  RGA. 

Further  discussion  of  the  translator  section  of  the  compiler  is 
beyond  the  intent  of  this  paper.  The  following  chapters  are  intended  as 
a  programmer's  introduction  to  GLYPNIR  as  well  as  a  user's  manual. 


HARDWARE 
CONTROL  LINKS 


MSTACK 


OPERAND  A 
DESCRIPTOR 


OPERAND  B 
DESCRIPTOR 


PEM  Control 
(no  links  to  MSTACK) 


Figure  h.     An  example  of  the  use  of  the  hardware  control  structure, 


Ik 


HARDWARE 
CONTROL  LINKS 


MSTACK 


.operand  a 
'descriptor 


.operand  b 
'descriptor 


ADB  63 


PEM 


Figure  5«  The  hardware  control  links  after  code  has  been 

generated  which  will  cause  operand  A  to  be  moved 
to  RGS  and  operand  B  to  be  loaded  into  RGA. 


2.   A  DESCRIPTION  OF  GLYPNIR  I 

Version  I  of  the  language  consists  of  a  one-pass  compiler 
implemented  with  the  ILLIAC  IV  Recursive  Descent  Translator  Writing 
System.  The  output  of  this  compiler  is  ILLIAC  IV  assembly  language. 
Version  I  realizes  many  of  the  constructs  of  GLYPNIR — notable  exceptions 
are  I/O  statements  and  paging  facilities. 

2.1  Registers  and  Data  Blocks 

In  ALGOL,  data  is  stored  as  simple  variables  or  arrays.  GLYPNIR 
does  not  allow  arrays,  but  it  does  allow  simple  variables  which  are  referred 
to  as  "registers".  These  are  declared  in  the  same  way  that  variables  are 
declared  in  ALGOL.  Most  data,  however,  is  stored  in  dynamically  allocated 
data  blocks.   This  data  is  not  referenced  by  name  as  are  arrays  but  by  a 
pointer  which  points  to  the  block.  This  is  accomplished  as  follows: 

Suppose  we  need  ten  words  of  storage  to  store  some  data.  Then 
we  would  call  the  system  storage  allocator  in  the  same  manner  in  which  we 
would  call  an  ALGOL  procedure: 

GETBLOCK(lO) 

This  causes  the  system  to  allocate  10  contiguous  words  of  storage  for  the 
programmer's  use.   In  order  to  use  this  block  of  storage,  we  must  have  a 
pointer  to  it.  GETBLOCK  is  a  procedure  whose  type  is  "pointer"  and  which 


-* 
As  this  paper  is  being  published,  work  is  beginning  on  Version 

II  which  will  include  more  general  pointer  structures,  fields,  and  control 

statements  as  well  as  I/O  statements  and  improved  machine  reference  features. 
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returns  the  value  of  a  pointer  pointing  to  the  storage  block.  Thus,  if 
we  write 

PNT  :=  GETBLOCK(IO); 

where  PNT  was  declared  to  be  a  pointer  register  (variable  with  type  pointer) 
then  we  can  always  refer  to  this  block  through  the  pointer  stored  in  PNT. 

In  order  to  refer  to  some  specific  data  in  this  block  we  need 
one  more  construct,  the  field  designator.  The  field  designator  indicates 
which  word  of  the  block  and  which  field  of  the  word  is  to  be  used  as  an 
operand.   For  example,  the  following  declaration  will  cause  the  identifier 
IN  to  be  associated  with  the  zero-th  word,  10th  through  2^th  bits  inclusive 
and  will  cause  the  resultant  value  to  be  treated  as  an  integer: 

INTEGER  FIELD  IN  [0,10,15]; 

Thus,  an  integer  field  in  the  block  obtained  above  could  be 
referenced  by  writing 

PNT.LN 

This  construct,  called  a  field  content  designator,  will  be  discussed  in 
more  detail  in  the  next  section.   It  is  sufficient  at  this  point  to  state 
that  field  content  designators  can  be  used  anywhere  that  variables  are 
used  in  ALGOL. 

The  use  of  the  function  GETBLOCK  was  described  above.  Actually, 
there  are  several  such  functions  which  allow  the  programmer  to  control  data 


-x- 

FREEBLOCK  and  GETBLOCK  are  not  the  actual  names-- see  Section 
2«9«2  for  the  correct  names  of  all  the  storage  allocation  routines. 
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storage.  These  will  all  be  explained  more  fully  in  Section  2.8.   However, 
one  procedure  should  be  mentioned  before  continuing  any  further.  This  is 
the  procedure  FREEBLOCK. 

Whenever  data  blocks  are  no  longer  needed,  they  must  be  explicitly 
returned  to  the  system.  This  is  done  by  executing  the  procedure  FREEBLOCK 
with  the  blocksize  and  a  pointer  to  the  block  as  parameters.  For  instance, 
in  the  example  above,  PNT  contains  a  pointer  to  a  block  of  size  10.  This 
block  can  be  returned  to  free  storage  by  executing  FREEBLOCK  (10, PNT). 
Only  then  will  the  space  in  this  block  become  available  for  later  GETBLOCK 
requests. 

It  has  been  mentioned  that  "registers"  are  the  GLYPNIR  equivalent 
of  ALGOL  simple  variables.  This  is  not  really  true.  Actually,  "registers" 
are  simulated  hardware  registers,  as  their  name  implies.  This  is  not  a 
trivial  distinction  especially  since  register  refers  to  ILLIAC  IV  registers. 
There  are  two  kinds  (and  several  types)  of  registers,  namely,  CU  and  PE 
registers.   CU  registers  represent  single  quantities  while  PE  registers 
represent  many  quantities,  one  associated  with  each  PE  in  the  array. 
Figure  6  illustrates  the  use  and  declaration  of  these  elements. 

BEGIN 

CU  REAL  REGISTER  TIME; 

PE  REAL  REGISTER  DISTANCE,  RATE; 

RATE  :=  DISTANCE/TIME; 
END 
Figure  6.  Use  and  declaration  of  CU  and  PE  pseudo  registers. 


FREEBLOCK  and  GETBLOCK  are  not  the  actual  names-- see  Section 
2.9.2  for  the  correct  names  of  all  the  storage  allocation  routines. 
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This  program  causes  the  values  stored  in  the  6k   PE  registers 
DISTANCE  to  be  divided  by  the  single  value  stored  in  CU  register  TIME  and 
the  results  are  stored  in  the  6k   PE  registers  RATE. 

In  addition  to  there  being  two  kinds  of  register,  there  are 
numerous  "types".  These  are  enumerated  in  the  following  table.   Of  the 
six  types  shown,  the  last  three  require  some  explanation. 


TABLE  1 
TYPES  AND  KINDS  OF  REGISTERS 


Type 

Real 

Integer 

Alpha 

Boolean 

Confined  Pointer 

Non- confined 
Pointer 


Kind 


CU 


PE 


yes 

yes 

yes 

yes 

yes 

yes 

yes 

no 

no 

yes 

yes 

-* 
yes 

Not  available  in  Version  I 


Boolean  values  in  GLYPNIR  are  not  single  values  as  they  are  in 
ALGOL.   Instead  they  represent  the  results  of  independent  tests  done  in 
all  (enabled)  PE's.  For  instance,  using  the  PE  real  registers  defined 
above,  the  following  "relation"  results  in  as  many  true-false  values  as 
there  are  (enabled)  PE's  in  the  configuration. 

DISTANCE  <  RATE 


Thus,  Boolean  registers  get  assigned  these  multiple  values.  This  will  be 
discussed  further  in  the  sections  describing  <Boolean  expressions>  and 
<for  statements>. 

GLYPNIR  allows  the  use  of  two  kinds  of  pointers,  confined  and 
non- confined.   Non- confined  pointers  are  allowed  to  point  from  one  PE  to 
another.   Confined  pointers  are  not  allowed  to  point  across  PE  boundaries. 

2.2  Field  Content  Designators 

Field  content  designators,  hereafter  abbreviated  FCD,  are  the 
principal  means  of  referencing  data  in  GLYPNIR.  An  FCD  may  designate  the 
contents  of  a  register  (either  a  GLYPNIR  register  or,  in  some  cases,  an 
actual  hardware  register)  or  it  may  designate  a  particular  field  within 
some  data  block.   Registers  were  introduced  in  the  last  section.  We  will 
begin  this  section  with  an  explanation  of  field  identifiers. 

2.2.1  Fields 

Through  the  use  of  field  declarations,  an  identifier  can  be 
associated  with  a  data  field.   It  is  important  to  understand  that,  in 
this  paper,  "field"  refers  not  only  to  some  part  of  an  ILLIAC  IV  word, 
but  to  a- particular  word  within  a  block  of  words  as  well.  For  instance, 
the  following  field  declaration  will  cause  the  identifier  "I"  to  be  asso- 
ciated with  the  field  indicated  in  Figure  7: 


INTEGER  FIELD  I[l,l6,k8]; 
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Word  0 


Word  1 


Word  2 


4 —  first  bit  l6 

4  kS   bits  long 


Word 
Block 


Figure  7.  The  integer  field  I[l,l6,48]. 


Notice  that  word  numbers  and  bit  numbers  both  start  at  zero.  Also  notice 
that  a  type  is  associated  with  this  field.  This  will  be  true  of  all  fields. 
The  various  field  types  are: 

ALPHA.:   Generally  used  to  hold  non-numeric  data  or  unsigned 

integers.  The  field  contents  are  treated  as  unsigned 
integers  when  used  in  arithmetic  statements  unless 
the  field  length  is  64  in  which  case  the  leftmost 
bit  is  considered  the  sign  bit. 
INTEGER:   Used  to  store  signed  integers.  This  field  may  be 
any  length  as  long  as  it  does  not  cross  a  word 
boundary.   However,  for  the  purpose  of  arithmetic, 
integer  quantities  are  treated  as  kQ   bit  fixed  point 
numbers.  Note  that  the  sign  bit  is  stored  as  the 
rightmost  bit  of  the  field. 
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CONFINED  POINTER  (POINT):   Used  to  store  "confined"  pointer.  . 

The  field  length  must  be  greater  than  or  equal  to  l6. 
NON-CONFINED  POINTER  (NPOINT):  This  is  used  to  store  "non- 
confined"  pointers  (pointers  which  may  point  across 
PE  boundaries).  The  field  length  must  be  greater 
than  or  equal  to  2k. 
REAL:   These  fields  are  used  to  store  real  numbers.  To 

utilize  ILLIAC  IV  hardware  effectively,  these  fields 
may  refer  to  any  word  within  a  block  but  they  can 
only  refer  to  one  of  the  following  word  parts: 
FULL:   bit  0,  sign  bit  of  mantissa 
bits  1-15,  exponent 
bits  16-63^  mantissa 
INNER:   bit  8,  sign  of  mantissa 
bits  9-15*  exponent 
bits  l6-39>  mantissa 
OUTER:   bit  0,  sign  of  mantissa 
bits  1-7 >  exponent 
bits  40-63,  mantissa 
For  further  information  on  real  fields,  see  the 
section  on  field  declaration  in  Chapter  3  of  this 
paper  and  the  section  on  data  formats  in  the  ILLIAC 
IV  manual. 
None  of  the  above  fields  may  cross  word  boundaries.  The  Version 
I  compiler  will  try  to  optimize  the  use  of  fields,  and  the  following 
suggestions  will  result  in  more  efficient  object  code: 
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1)  Right  justify  fields  when  possible.  This  applies 
especially  to  pointer  fields. 

2)  ALPHA,  and  REAL  fields  should  be  as  long  as  possible 
without  interfering  with  other  fields. 

3)  ALPHA  fields  should  be  used  to  store  integers  unless 
the  integers  might  be  negative. 

It  is  not  necessary  for  all  fields  to  be  distinct—fields  may 
be  defined  within  other  fields.  For  example,  the  ALPHA  field  EX  defined 
below  can  be  used  to  alter  the  exponent  part  of  the  REAL  field  X: 

ALPHA  FIELD  EX  [0,1,15]; 
REAL  FIELD  X[0,FULL]  . 

Also,  the  ALPHA  field  AB  can  be  used  to  operate  on  the  absolute  value  of 
the  INTEGER  field  IN  in  the  following: 

ALPHA  FIELD  AB  [0,10,1^]; 
INTEGER  FIELD  IN  [0,10,15]  • 

When  the  contents  of  a  field  are  specified  as  an  operand  for 
some  operation,  the  following  actions  are  taken  before  the  operations 
are  performed.   (This  includes  the  unary  alphanumeric  operation  "C0MP" 
explained  later.) 

l)   If  the  field  is  less  than  64  bits  in  length,  then 
the  field  is  right  justified  and  high  order  bits 
filled  with  zeroes.   (The  only  exception  to  this 
is  REAL  fields.) 
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2)  If  the  field  is  an  INTEGER  field,  then  the  sign  bit 
which  is  in  the  least  significant  (rightmost)  bit 
position  is  shifted  end  around  into  the  correct  sign 
bit  position. 

These  actions  do  not  affect  other  fields  in  the  same  word  unless 
those  fields  overlap  the  designated  field. 

2.2.2  Field  Content  Designators 

FCD's  are  constructed  from  register  identifiers  and  field 
identifiers  as  follows: 

<fcd>  : :=  <register  identifier>  | 

<fcd>  •  <field  identified 

Thus,  an  FCD  is  a  list  of  identifiers  separated  by  periods.  All  except 
the  last  identifier  must  be  of  type  pointer  (confined  or  non-confined) . 
The  last  identifier  determines  the  type  of  the  FCD.   Some  examples  will 
help  to  clarify  this.  The  identifiers  used  in  the  following  FCD's  are 
defined  in  Figure  8  (page  25). 

1)  PCPNT1.P.I    has  type  INTEGER 
•  2)   PCPNT1.P.P.A  has  type  ALPHA 

3)  PRL  has  type  REAL 

h)      PCPNT1.P.P    has  type  (CONFINED)  POINTER 

5)   PCPNT1.I.A    is  invalid  since  I  is  not  a  pointer  field 

FCD's  work  by  specifying  a  pointer  chain  which  eventually  points 
to  some  data  block.  The  last  identifier  in  the  FCD  then  indicates  some 
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field  -within  that  block.   (in  the  special  case  where  the  FCD  is  a  single 
identifier,  as  in  3  above,  then  the  contents  of  that  register  are  designated. 
Designation  of  fields  within  registers  is  not  allowed  in  Version  I.)  For 
example,  the  data  designated  by  PCPNT1.P.I  is  the  field  I  of '  the  block 
pointed  to  by  the  field  P  of  the  block  pointed  to  by  the  pointer  in  register 
PCPNT1. 

At  this  point  the  reader  should  be  able  to  work  through  Figure  8 
with  the  aid  of  Figure  9«  This  program  does  essentially  nothing,  but  its 
study  should  be  instructive.   It  contains  only  three  constructs  which  have 
not  been  discussed  yet:  assignment  statements,  expressions  and  GETPEB 
(storage  allocation,  Section  2.9*2),  but  this  should  not  cause  any  trouble. 

One  complication  arises  in  the  use  of  non- confined  pointers  in 
FCD's.   The  use  of  non- confined  pointers  in  FCD's  which  begin  with  PE 
pointer  registers  (confined  or  otherwise)  can  lead  to  ambiguities  in  the 
specification  of  data.   The  reader  need  not  worry  about  this,  however, 
since  such  use  of  non- confined  pointer  fields  will  not  be  allowed  in  Version 
I.   Non-confined  pointers  may  be  used  in  FCD's  only  if  the  FCD  begins  with 
a  CU  pointer  register.  This  restriction  will  be  lifted  in  later  versions. 

It  -will  be  pointed  out  in  the  next  section  that  explicit  modifica- 
tion of  pointer  values  will  not  be  allowed  in  Version  I.   That  is,  a  state- 
ment such  as 

PCPNT1  :  =  PCPNT1  +  1 

is  illegal.   There  is,  however,  a  way  to  implicitly  modify  a  pointer  when 
it  is  used.   This  is  called  pointer  indexing  and  is  accomplished  as  follows. 


BEGIN 


PE  CONFINED  POINTER  REGISTER   PCPNT1,  PCPNT2; 

PE  REAL  REGISTER  PRL; 

CU  REAL  REGISTER  CRL; 

INTEGER  FIELD  I[0,4o,24]; 

ALPHA  FIELD  A[ 0,0,7]; 

CONFINED  POINTER  FIELD  P[ 1,32, 32]; 

REAL  FIELD  X[0,  INNER]; 

PCPNT1  :=  GETPEB(2); 

PCPNT2  :=  GETPEB(2); 

PCPNT1.P  :=  GETPEB(2); 

PCPNT2.X  :=  352.9; 

PCPNT2.A  :  =  32; 

PCPNT1.P.I  :=  -10; 

CRL  :  =  352.6; 

PRL  :=  (CRL  -  PCPNT2.X)  x  PCPNT2.A/PCPNT1.P.I; 


END 


Line  Ref.  No, 
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1 
2 

3 
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7 
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9 
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12 
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15 
16 


Figure  8.   Illustration  of  the  use  of  FCD's  to  reference  data. 
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Figure  9-   Illustration  of  the  state  of  several  PE  memories  after 
line  ik   of  figure  8  has  "been  executed.  All  PE  memories 
will  look  the  same  in  this  case. 
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Suppose  we  would  like  to  make  use  of  a  vector  of  numbers  in  each 
PE.   Since  the  vector  is  large,  we  do  not  want  to  define  different  fields 
in  order  to  reference  each  word  in  the  vector.  The  program  of  Figure  10 
illustrates  how  this  might  be  accomplished  using  pointer  indexing. 

BEGIN 

PE  CONFINED  POINTER  REGISTER  PR; 

CU  INTEGER  REGISTER  1} 

REAL  FIELD  X[0,FULL]; 

PR  :  =  GETBLOCK(lOO); 

FOR  I  :=  0  STEP  1  UNTIL  99  DO 
PR.[I]X  :=  I; 
END 

Figure  10.   Example  of  the  use  of  pointer  indexing* 

The  construct  "[I]"  in  the  FCD  above  is  called  a  pointer  index. 
Its  effect  is  to  increase  the  value  of  the  pointer  stored  in  PR  by  the 
absolute  value  of  the  integer  stored  in  I  without  actually  changing  the 
value  stored  in  PR.   Pointers  normally  point  to  the  zero-th  word  of  a 
block,  so  the  effect  of  using  the  pointer  index  is  to  cause  the  pointer 
to  reference  the  I-th  word  of  the  block.   Since  fields  always  specify 
data  relative  to  the  value  of  a  pointer,  in  this  case  the  field  X  will 
cause  the  assignment  statement  to  reference  the  zero-th  word  relative 
to  the  indexed  value  of  the  pointer.   Thus,  in  Figure  10,  each  word  within 
the  block  (in  each  PE)  will  be  initialized  to  the  real  value  corresponding 
to  the  word  number  within  that  block. 
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It  would  be  nice  if  we  could  use  any  arithmetic  expression  as 
an  indexing  element.   Unfortunately,  Version  I  will  only  allow  literal 
values  (unsigned)  or  registers  to  be  used  as  indexing  elements.   This 
restriction  will  be  lifted  in  later  versions.   (if  registers  are  used, 
they  may  be  either  PE  or  CU  registers,  and  they  must  be  of  type  REAL, 
INTEGER,  or  ALPHA.) 

2.3  Expressions 

Expressions  in  GLYPNIR  are  really  easy  to  understand  once  the 
mechanics  of  data  designation  are  understood.  There  are  four  types  of 
expressions,  each  of  which  we  will  examine  shortly.   In  all  of  them,  the 
operands  are  some  type  of  field  content  designator  or  literal.   Version 
I  of  GLYPNIR  will  not  allow  the  conditional  expressions  of  ALGOL.   With 
the  exception  of  primaries  and  conditional  expressions,  arithmetic  and 
Boolean  expressions  in  GLYPNIR  are  almost  identical  to  those  in  ALGOL. 

2.3*1  Boolean  Expressions 

There  are  only  two  differences  between  GLYPNIR  and  ALGOL  Boolean 
expressions.   The  first  difference  is  the  values  in  which  their  evaluation 
may  result,  and  the  second  is  the  effect  they  may  have  on  program  execution. 
The  latter  will  be  discussed  in  the  sections  on  <if  statements>  and  <for 
statements>.  Boolean  values  were  mentioned  briefly  in  connection  with 
Boolean  registers,  but  the  evaluation  of  Boolean  expressions  will  require 
further  analysis. 

Boolean  values  ultimately  result  from  Boolean  literals  or  from 
the  evaluation  of  relations.  A  Boolean  literal  is,  in  opposition  to 
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ALGOL,  a  logical  bit  pattern  which  may  result  from  a  numerical  constant 
(probably  expressed  in  octal).   Each  bit  corresponds  to  a  true  or  false 
value  for  some  PE  in  the  current  configuration.  This  situation  is  simply 
a  reflection  of  the  result  of  evaluating  relations. 

As  in  ALGOL,  relations  are  simply  comparisons  between  arithmetic 
expressions.  Unlike  ALGOL,  arithmetic  expressions  can  have  many  values-- 
a  different  value  for  each  PE  in  which  the  expression  is  evaluated.  Thus, 
relations  are  multi-valued  since  they  result  from  comparisons  done  in  many 
EE's. 

At  the  time  when  relations  are  evaluated,  some  PE's  will  be 
enabled  while  other's  will  be  disabled  (this  is  explained  under  <for 
statements>) .  A  relation  is  evaluated  in  such  a  way  that  true  values  are 
returned  in  all  disabled  PE's.   This  is  due  to  the  fact  that,  technically, 
arithmetic  expressions  have  no  value  in  disabled  PE's. 

2.3*2  Arithmetic  Expressions 

Arithmetic  expressions  are  again  very  similar  to  ALGOL.  There 
are,  however,  two  differences:   l)  There  will  be  no  exponentiation 
operation  (t)  in  Version  I,  and  2)   primaries  are  defined  as  follows: 

<primary>  : :=  (<arithmetic  expression>) 
<fcd>+  | 
<number>  | 
<alphameric  expression> 


f 

Type  must  be  real  or  integer. 
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The  principal  difference  to  be  noted  here  is  the  presence  of 
<alphameric  expression>.   These  are  explained  next.   It  is  sufficient  to 
state  here  that  the  following  is  a  valid  <arithmetic  expression>  (using 
the  fields  and  registers  defined  in  Figure  8,  page  25). 

PRL  +  CRL  X  PCPNT1.A  EOR  PCPNT2.A 

This  will  be  evaluated  as  though  parentheses  were  inserted  as 
follows: 

PRL  +  (CRL  X  (PCPNT1.A  EOR  PCPNT2.A)) 

The  result  of  the  alphameric  expression  will  be  treated  as  an  unsigned 
integer. 

All  integers  are  treated  as  hQ   bit  fixed  point  numbers.  Thus, 
alphameric  fields  longer  than  ^8  bits  will  have  the  excess  high  order 
bits  truncated  when  used  in  arithmetic  expressions. 

2.3*3  Alphameric  Expressions 

Alphameric  expressions  have  been  introduced  for  two  reasons: 
l)   to  allow  logical  operations  on  words,  and  2)   to  enable  the  programmer 
to  utilize  several  special  hardware  operations  on  ILLIAC  IV.  The  syntax 
follows. 


There  is  a  minor  qualification  here.   Results  of  alphameric 
expressions,  when  used  in  arithmetic  expressions,  are  treated  like  unsigned 
integers  unless  the  evaluation  of  the  expression  causes  the  zero-th  (most 
significant)  bit  to  be  turned  on. 
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<alphameric  expression>  : :=  <alphameric  expression>  <alphameric  operator> 
<alphameric  primary>  | 
<alphameric  primary> 
<alphameric  operator>  ::  =  WAND  |  WOR  |  WIMP  |  WEQU  |  EOR  |  NOR  |  NAND  | 

ADB  |  SBB  |  ADD  |  SUB 
<alphameric  primary>  ::=  (<alphameric  expression>) 

COMP  <alphameric  primary>  | 
<fcd  (type  alpha)>  | 
<string> 

Notice  that  due  to  the  large  number  of  operators,  no  precedence 
is  established  between  operators—operations  are  performed  from  left  to 
right  unless  parentheses  are  used.   The  functions  of  the  operators  are 
specified  in  Table  2. 

We  will  reiterate  at  this  point  that  wherever  fields  whose  length 
is  less  than  6U  bits  are  used  as  operands  in  alphameric  expressions,  the 
field  contents  are  right  justified  and  high  order  bits  filled  with  zeroes 
before  any  operation  is  performed. 

Later  versions  of  GLYPNIR  will  include  more  ILLIAC  IV  instructions 
as  alphameric  operators.  These,  together  with  the  ability  to  reference 
actual  ILLIAC  IV  hardware  registers  provide  a  limited  assembly  language 
capability  in  the  language. 

2.3«^  Pointer  Expressions 

Pointer  expressions  are  extremely  simple.  Their  syntax  follows. 
<pointer  expression>  ::=  <fcd  (type  confined  or  non-confined  pointer)> 


TABLE  2 
DEFINITION  OF  A   OP  B 
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OP 

FUNCTION 

COMP 

Complement  all  bits  of  operand 

WAND 

Logical  "AND"  of  operands 

WOR 

Logical  "OR"  or  operands 

WIMP 

Logical  "IMP"  of  operands 

WEQV 

Logical  "EQV"  of  operands 

EOR 

COMP  (A  WEQV  B) 

NOR 

COMP  (A  WOR  B) 

NAND 

COMP  (A  WAND  B) 

ADB 
SBB 
ADD 
SUB 

These  are  special  ILLIAC  IV  instructions. 
See  the  appropriate  section  of  the  ILLIAC 
IV  manual. 
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Notice  that  no  explicit  pointer  modification  will  be  allowed 
in  Version  I. 

2.^4  Assignment  Statements 

Assignment  statements  are  simply  one  way  of  moving  data  from 
one  place  to  another.   In  addition  to  moving  data,  assignment  statements 
may  invoke  routines  which  change  data  from  one  form  to  another.  Table  3 
lists  the  allowed  combinations  of  right  and  left  hand  sides  and  the  con- 
versions which  are  automatically  invoked. 

In  addition  to  differing  in  type,  the  right  and  left  hand  sides 
may  differ  in  kind,  that  is,  one  may  be  a  multiple  (PE)  quantity  while 
the  other  is  a  single  (CU)  quantity.  These  possibilities  are  enumerated 
in  Table  h. 

Up  to  this  point  we  have  made  no  provision  for  moving  multiple 
data  from  one  PE  to  another,  that  is,  for  utilizing  the  ILLIAC  IV  ROUTE 
instruction.   This  can  be  done,  albeit  very  inefficiently,  by  proper  use 
of  non-confined  pointers,  but  the  use  of  these  will  be  severely  restricted 
in  Version  I.  For  this  reason  we  will  now  introduce  a  new  construct  into 
the  assignment  statement. 

<assignment  statement>  : :=  <fcd>  :=  <expression>  | 

<fcd>  :=  [<r outing  index>]  <expression> 
<routing  index>        : :=  <arithmetic  expression> 

The  effect  of  the  routing  index  involves  the  concept  of  the 
MODE  register  which,  unfortunately,  is  not  discussed  until  Section  2.6 
of  this  chapter.  Those  who  do  not  already  know  about  the  MODE  register 
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TABLE  3 

ASSIGNMENT  STATEMENTS,  RIGHT  AND  LEFT 
SIDE  TYPE  DIFFERENCES 


Right  Hand  Side  Type 


Left  Hand  Side  Type 

Real 

Integer 

Alpha 

Boolean 

Confined  Pointer 

Non-Confined  Pointer 


Real 

Integer 

Alpha 

Boolean 

Confined 
Pointer 

Non-Confined 
Pointer 

7 

1 

1 

X 

X 

X 

2 

7 

y 

X 

X 

X 

2,3 

3 

y 

X 

X 

X 

X 

X 

X 

V 

X 

X 

X 

X 

X 

X 

y 

X 

X 

X 

X 

X 

X 

y 

y  =  No  conversion  necessary 


X  =  Not  allowed 


1.  Usual  conversion. 

2.  RHS  is  rounded  and  truncated. 

If  the  value  of  the  RHS  is  too  large  for 
U8-bit  fixed  point  representation,  an 
overflow  condition  results. 
3«  A  negative  RHS  will  result  in  an  overflow 
condition  unless  the  LHS  is  a  register  or 


6U-bit  field. 


TABLE  k 

ASSIGNMENT  STATEMENTS,  RIGHT  AND  LEFT 
SIDE  KIND  DIFFERENCES 


Left  Hand  Side 
Multiple  (PE) 
Simple  (CU) 


Right  Hand  Side 


Multiple 

Single 

V 

1 

2 

y 

•/  =  No  conversion  required. 


1.  Each  element  specified  by  the  LHS  received 
the  same  single  value  which  is  specified 
by  the  RHS. 

2.  The  single  destination  specified  by  the  LHS 
receives  the  logical  "OR"  of  all  the  values 
specified  by  the  RHS. 
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should  skip  the  remainder  of  this  section  and  return  after  reading 
Section  2.6. 

The  routing  index  allows  the  programmer  to  specify  that  the 
value  resulting  from  the  evaluation  of  an  expression  in  one  set  of  PE's 
is  to  be  assigned  to  the  left  hand  side  as  evaluated  in  another  set  of 
PE's.  When  an  assignment  statement  is  executed,  the  following  steps  are 
taken. 

1)  The  value  of  the  routing  index  is  determined  and  the 
MODE  register  is  shifted  right  (end  around)  by  this 
amount. 

2)  With  the  new  mode  configuration  in  effect,  the  RHS 
is  evaluated. 

3)  The  results  of  the  RHS  are  routed  left,  and  the  MODE 
register  is  shifted  left,  by  the  amount  of  the  routing 
index. 

h)     The  LHS  is  evaluated  and  the  assignment  performed 
under  the  effect  of  the  original  mode  configuration. 

An  example  may  help  to  clarify  this.  Suppose  the  MODE  register 
contains  1  0  1  0  1  ...  .  Thus,  all  odd  numbered  PE's  are  disabled,  even 
numbered  PE's  are  enabled.   If  the  assignment  statement 

PNTR.P.X  :=  [1]  PNTR.X  +  PNTR.Y 

is  executed,  then  the  expression 

PNTR.X  +  PNTR.Y 
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will  be  evaluated  1  PE  to  the  right  of  all  enabled  PE's  (odd  PE'a),  the 
result  will  be  routed  left  (end  around)  one  PE,  and  the  result  assigned 
to  PNTR.P.X  in  all  even  numbered  PE's. 

Notice  that  the  routing  index  is  only  relevant  if  both  the 
right  and  left  hand  sides  specify  multiple  quantities  (i.e.,  PE  quantities) 
Thus,  use  of  the  routing  index  is  only  allowed  under  this  condition. 

2.5  IF  Statements 

The  only  difficulty  encountered  in  the  understanding  of 
<if  statements>  is  in  the  effect  of  the  <Boolean  expression>.  As  men- 
tioned earlier,  Boolean  expressions  result  in  multiple  true-false  values, 
one  for  each  PE.   In  the  context  of  <if  statements>,  the  Boolean  expres- 
sion is  considered  to  be  true  if  and  only  if  the  expression  is  true  for 
all  PE's. 

At  this  point  one  might  ask  if  there  is  not  some  facility  for 
having  a  statement  executed  in  just  those  PE's  which  do  return  a  true 
value.   That  is,  for  all  PE's  such  that  the  Boolean  expression  is  true 
do  the  following  statement.   There  is,  and  such  a  statement  would  be 
written 

FOR  ALL  <Boolean  expression>  DO  <statement>  . 

This  is  just  one  type  of  <for  statement>  and  next  to  FCD's,  it 
is  probably  the  most  important  construct  in  GLYPNIR.  FOR  statements  are 
the  subject  of  the  next  section. 


38 


2.6  FOR  Statements 

There  are  two  kinds  of  <for  statement>  in  GLYPNIR.  The  first 
is  similar,  at  least  syntactically,  to  the  <for  statement>  of  ALGOL.  The 
other  is  used  to  set  the  MODE  register. 

The  syntax  for  the  first  type  of  for  statement  is: 

<for  statement>  : :=  FOR  <register  identifier>  := 

<arithmetic  expression> 
STEP  <arithmetic  expression> 
UNTIL  <arithmetic  expression> 
DO  <unlabelled  statement> 

If  any  of  the  above  arithmetic  expressions  return  multiple  values, 
then  independent  loops  will  be  established  in  all  enabled  PE's.   (Those 
PE's  which  finish  the  loop  sooner  than  others  will  mode  themselves  off.) 
An  example  of  such  a  statement  is 

FOR  I  :=  1  STEP  PNTR.X  UNTIL  PNTR. FINAL  DO  <S> 

This  is  equivalent  to  the  program  of  Figure  11. 


BEGIN 

LABEL  LI,  L2; 

BOOLEAN  REGISTER  SAVEMODE; 

PE  REAL   INC, LIMIT; 

SAVEMODE  :=  MODE; 

INC  :=  PNTR.X; 

LIMIT  :=  PNTR. FINAL; 

I  :=  lj 

Ll:   IF  I  >  LIMIT   THEN  GO  TO  L2; 
MODE  :=  MODE  AND  I  <  LIMIT; 
<S>; 

I  :=  I  +  INC; 

GO  TO  Ll; 
L2:   MODE  :=  SAVEMODE 
END 


Figure  11.   Illustration  of  the  effect  of 
one  type  of  <for  statements 


Notice  the  use  of  the  hardware  register  MODE  in  the  above 
program.  This  register  will  be  explained  more  fully  in  relation  to  the 
second  type  of<for  statement>, but  we  will  state  now  that  MODE  contains 
the  current  mode  bit  configuration  and  the  assignment  of  any  Boolean 
value  to  this  register  results  in  the  resetting  of  the  mode  bits  (RGE 
and  RGE1). 
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The  syntax  for  the  second  type  of <for  statement>  is 

<for  statement>  ::=  FOR  ALL  <Boolean  expression>  DO  <unlabelled  statements 

FOR  ANY  <Boolean  expression>  DO  <unlabelled  stateraent> 

The  effect  of  the  "FOR  ALL"  statement  is  to  construct  a  new  mode  word  by 
performing  a  logical  "AND"  between  the  result  of  the  Boolean  expression 
and  the  current  mode  word.   The  current  mode  word  (contents  of  MODE)  is 
then  pushed  into  the  mode  stack  and  the  new  mode  word  becomes  the  current 
mode  word.  After  the  statement  following  the  DO  is  executed,  the  old  mode 
word  is  restored  to  the  mode  register  and  becomes  the  current  mode  word 
again.  An  example  would  be 

FOR  ALL  I  <PNTR.  FINAL  DO  <S> 

An  equivalent  program  for  this  is  the  program  of  Figure  12. 

BEGIN 

LABEL  LI; 

PUSHMODE  (I  <  PNTR. FINAL  AND  MODE); 

IF  NOT  MODE  THEN  GO  TO  LI; 

<S>; 
LI:   POFMODE 
END 


Figure  12.   Illustration  of  the  effect  of  executing 
the  second  type  of  <for  statement>. 


The  procedures  PUSHMODE  and  POPMODE  used  above  cause  Boolean 
values  to  be  pushed  and  popped  on  the  system  mode  word  stack  (the  top 
of  which  is  the  special  MODE  register).   Notice  that  the  statement  follow- 
ing the  DO  is  skipped  if 

MODE  AND  <Boolean  expression> 

returns  false  values  for  all  PE's. 

The  statement  following  the  DO  can  be  thought  of  as  being  within 
the  "scope"  of  the  <for  statements  Thus,  all  operations  performed  in 
this  statement  (which  may  be  a  compound  statement  or  a  block)  are  performed 
under  the  influence  of  the  mode  word  which  was  created  by  the<for  statements 
Of  course,  some  <for  statements>  may  be  under  the  influence  of  other  <for 
statement s>,  but  this  causes  no  problem  as  successive  mode  words  are  simply 
pushed  on  the  mode  stack. 

The  execution  of  a  <go  to  statement>  within  the  scope  of  a  <for 
statement>may  cause  the  mode  stack  to  be  popped,  depending  on  the  destina- 
tion of  the  label  transferred  to.  An  example  should  clarify  this.  Figure 
13  shows  a  case  where  a  <go  to  statement>  is  executed  within  the  scope  of 
a  <for  statement>  where  the  destination  label  is  not  within  the  scope  of 
the  same  <for  statement>.   In  this  case,  the  <go  to  statement>  will  cause 
the  mode  stack  to  be  popped  once  before  the  transfer  is  performed,  thus 
restoring  the  original  mode  configuration. 

Figure  13  is  an  example  of  a  particularly  poor  way  to  compute 
e  .   It  should  be  instructive,  however,  to  stop  at  this  point  and  work 
through  an  example. 
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Line  Ref.  No. 

BEGIN  1 
%                       COMPUTATION  OF  E  TO  THE  X  USING  2 

io       MACLAURIN  SERIES.   THE  ARGUMENTS  ARE  3 

io       INITIALLY  STORED  IN  THE  PE  REGISTERS  k 

<fo       EX,  GLOBAL  TO  THIS  BLOCK.  5 

1o  6 

LABEL  AGAIN;  7 
PE  REAL  REGISTER  NEW,  TERM,  I;  8 

9 

NEW  *-  1  +  EX;  TERM  *-   EX;  I  *-   1;  10 

11 

AGAIN:     FOR  ALL  TERM  >  1@-10  DO  12 

BEGIN  13 

I  -  I  +  1;  Ik 

TERM  -  TERM  x  EX/ 1;  15 

NEW  *-   NEW  +  TERM;  l6 

GO  TO  AGAIN  IT 

END;  18 

EX  *-  NEW  19 

END  20 


Figure  13 •   Illustration  of  an  implicit  POPMODE  caused  by- 
execution  of  <go  to  statements.   Notice  the  "%" 
convention  used  for  comments.   Line  numbers  have 
been  added  for  reference  only. 
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We  assume  that  we  want  to  compute  e  for  (conveniently)  6k 
values  of  x.   These  values  have  been  stored  in  the  64  PE  pseudo  registers 
EX  previous  to  entry  into  the  block  of  Figure  13 •   Upon  exit  from  this 

X 

block  EX  will  contain  the  respective  value  of  e  .   We  also  assume  that 
the  mode  register  will  contain  all  ones  upon  entry  to  the  block. 

At  line  12,  a  new  mode  word  is  put  into  effect,  the  old  one 
being  pushed  into  the  mode  stack.   The  new  mode  word  will  contain  ones  in 
bit  positions  corresponding  to  PE's  in  which  the  contents  of  TERM  are 
greater  than  1  x  10  "  ,  and  which  were  formerly  enabled  (which  in  this 
case  includes  all  of  them).   The  (compound)  statement  following  the  DO 
is  then  executed  under  the  influence  of  this  new  mode  word.   Thus,  the 
contents  of  I,  TEEM,  and  NEW  will  be  altered  only  in  those  PE's  where 
TERM  >  1@-10. 

At  line  17  a  transfer  to  AGAIN  is  performed  causing  the  original 
mode  word  to  be  popped  from  the  mode  stack  and  restored  to  the  MODE  register. 

When  the  content  of  TERM  is  less  than  or  equal  to  1  x  10    in 
all  PE's,  control  will  pass  directly  from  line  12  to  line  19  where  the 
final  result  is  assigned  to  EX.   Control  then  leaves  this  block. 


2.7  Blocks,  Compound  Statements,  and  Labels 

The  first  thing  to  be  noted  about  blocks  and  compound  statements 
in  GLYPNIR  is  that  there  are  no  compound  statements.  Anything  which  begins 
with  BEGIN  and  ends  with  END  is  a  block,  regardless  of  whether  declarations 
appear  within  the  block  head.   Having  thus  simplified  matters,  we  will 
proceed  to  confuse  them. 
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Labels  must  "be  declared.  Further,  they  must  be  declared  in 
the  innermost  "block"  in  which  they  are  used.  Figure  li+  is  an  example 
of  illegal  use  and  declaration  of  labels. 

BEGIN 

LABEL  LI; 
BEGIN 

LI:  A  :=  1; 

END 
END 


Figure  lk.     An  example  of  the  illegal  use  of  a 

label  which  would  result  in  a  fatal  error. 


Labels  may  be  used  in  <go  to  statement s>  anywhere  within  the 
scope  of  the  label  declaration.  Thus,  a  block  may  be  exited  from  anywhere, 
but  it  is  impossible  to  enter  a  block  except  through  its  head. 

All  identifiers  must  be  declared  before  they  can  appear  elsewhere 
in  a  program.  Notice  that  this  applies  to  the  use  of  identifiers  in  sub- 
routine declarations  where  the  identifiers  and  procedure  are  both  local 
to  the  same  block.   This  restriction  is  imposed  by  the  one-pass  nature 
of  the  Version  I  compiler. 

2.8  Subroutines 

GLYPNIR  subroutines  are  similar  to  both  FORTRAN  subroutines 
and  ALGOL  procedures;  i.e.,  they  are  declared  like  ALGOL  procedures,  but 
they  act  like  FORTRAN  subroutines.  The  syntax  for  a  subroutine  declaration 
is: 


<subroutine  declaration>  ::= 

SUBROUTINE  Subroutine  identifier^  <formal  parameter  part>; 
<sub routine  body>  | 

<type>  SUBROUTINE  Subroutine  identified  <formal  parameter  part>; 
< sub routine  body> 
<subroutine  body>  ::=  <unlabelled  statement> 
<subroutine  identifier>  ::  =  <identifier> 
<formal  parameter  part>  ::  = 

(<formal  parameter  specification  list>) 

<empty> 
<formal  parameter  specification  list>  ::= 

<formal  parameter  specification>  I 

<formal  parameter  specification  list>, 

<formal  parameter  specification> 
<formal  parameter  specif ication>  ::  = 

<type>  <register  identifier>  | 

<type>  OUT  <register  identifier> 

Notice  that  the  specification  of  formal  parameters  is  done  in 
the  parameter  list  itself.   In  addition  to  specifying  the  type  of  the 
formal  parameters,  a  parameter  may  also  be  specified  to  be  an  output 
parameter  (this  is  related  to  the  call  by  name  of  ALGOL). 

If  the  actual  parameter  corresponding  to  a  formal  output  parameter 
is  a  simple  register  identifier,  then  this  register  will  be  assigned  the 
value  last  held  by  the  corresponding  formal  parameter  after  exit  from  the 
subroutine. 
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Identifiers  appearing  within  a  subroutine  body,  which  are  neither 
local  to  the  body  nor  formal  parameters,  assume  the  definition  of  those 
identifiers  at  the  point  of  the  subroutine  declaration,  regardless  of 
redeclaration  of  the  identifiers  later  in  the  same  block  head  or  their 
meaning  at  the  point  where  the  subroutine  is  called.   This  is  in  differ- 
ence with  formal  ALGOL  but  conforms  to  the  convention  established  in 
Burroughs  Extended  ALGOL.   Figure  15  illustrates  this  point.  The  last 
statement  of  the  program  (line  10)  will  assign  the  value  20  to  the  regis- 
ter Y.   If  line  7  had  appeared  between  lines  h   and  5,  then  line  10  would 
result  in  Y  receiving  the  value  10. 

BEGIN  1 

PE  REAL  REGISTER  X,  Y;  2 

X  :=  10;  3 

BEGIN  h 

SUBROUTINE  ASSIGN;  5 

BEGIN  X  :=  20;  END;  6 

PE  REAL  REGISTER  X;  7 

ASSIGN;  8 

END;  9 

Y  :  =  X;  10 

END  11 


Figure  15.   Illustration  of  the  scope  of  identifiers 

used  in  subroutine  bodies.  The  last  statement 
assigns  the  value  20  to  Y.   (Line  numbers  are 
for  reference  only.) 
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The  syntax  for  a  subroutine  call  is: 

<subroutine  call>  ::= 

<subroutine  identifier>  <actual  parameter  part> 
<actual  parameter  part>  ::= 

(<actual  parameter  list>) 

<empty> 
<actual  parameter  list>  : := 

<actual  parameter>  | 

<actual  parameter  list>  ,   <actual  parameter> 
<actual  parameter>  ::= 

<register  identifier>  | 

<expression>  | 

<empty> 
<subroutine  statement>  ::=  <subroutine  call> 
<function  designator>  : :=  <subroutine  callV 

The  actual  parameters  of  the  subroutine  call  correspond  in  a  one-to-one 
manner  with  the  formal  parameters  appearing  in  the  subroutine  declaration. 
However,  any  of  the  actual  parameters  may  be  empty  (see  Figure  l6). 
Further,  the  number  of  actual  parameters  may  be  less  than  the  number  of 
formal  parameters.  An  empty  parameter  is  equivalent  to  an  occurrence 
of  a  literal  zero  (FALSE  if  Boolean). 


A  subroutine  may  be  used  as  a  function  designator  if  it  has 
been  declared  with  a  type. 
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Normally,  actual  parameters  should  "be  register  identifiers  when 
the  actual  parameter  corresponds  to  a  formal  parameter  specified  as  an 
output  parameter.   However,  if  this  is  not  the  case,  then  for  that  partic- 
ular subroutine  call  the  parameter  will  "be  considered  as  an  input  parameter 
only. 

Correspondence  of  type  and  kind  between  actual  and  formal 
parameters  follows  the  same  rules  summarized  in  Tables  3  and  k   for  assign- 
ment statements. 

Figure  l6  is  an  example  of  the  declaration  and  call  of  a 
subroutine.  The  program  of  Figure  17  is  an  equivalent  program  and  illus- 
trates the  action  taken  on  entry  and  exit  from  a  subroutine. 

Restrictions  -  Recursive  use  of  subroutines  is  not  allowed. 
If  a  subroutine  is  declared  with  a  type,  then  the  use  of  the  subroutine 
identifier  within  the  subroutine  body  is  equivalent  to  the  use  of  a  regis- 
ter identifier  with  the  same  type. 

<go  to  statement s>  which  reference  labels  external  to  the 
subroutine  are  not  allowed. 

2.9  Standard  Functions 

A  number  of  standard  functions  will  be  provided  in  GLYPNIR. 
Most  of  these  will  not  be  available  in  Version  I.  Those  which  will  be 
available  are  described  in  this  section. 
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BEGIN 
PINT  S; 
CREAL  T,  Uj 

PREAL  SUBROUTINE  R(PINT  I,  PALPHA  A,  PREAL  OUT  X, 
PREAL  Y,  CALPHA  OUT  CX); 
<subroutine  body>; 


R(T  +  U,,S); 


END 


Figure  l6.  Example  of  declaration  and 
call  of  a  subroutine. 
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BEGIN 
PINT  S; 
CREAL  T,  U; 

LABEL  LI,  L2; 

PREAL  Rl,  XI,  Yl; 
PALPHA  Al; 
PINT  II; 
CALPRA  CXI; 

LI :   BEGIN 

PREAL  R,  X,  Y; 
PALPHA  A; 
PINT  I; 
CALPHA  CX; 
I  *-   II; 
A  *-  Al; 

X  -  XI; 
Y  ^  Yl; 
CX  «-  CXI; 
<subroutine  body>; 

XI  «-  X; 
CXI  *-  CX; 
Rl  4-  R; 
GO  TO  L2; 
END; 

• 

II  *-   T  +  U; 
Al  «-  0; 
XI  «-  S; 
Yl  ^-  0; 
CXI  4-   0; 
GO  TO  LI; 
L2:   S  *-   XI; 

END 

Figure  17 •   Illustration  of  equivalent  actions  performed 
during  a  subroutine  declaration  and  call. 
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2.9«1  ALGOL  Functions 

1.  ABS  (<arithmetic  expression>) 

2.  SIGN  (<arithmetic  expression>) 

3.  ENTIER  (<arithmetic  express ion>) 

2.9*2  Storage  Allocation 

a)  GETPEB  (<arithmetic  expression>) 
Type  -  PE  confined  pointer. 

Action  -  Causes  allocation  of  a  block  of  words  in 
each  enabled  PE.   Returns  a  pointer  to  this  block. 
Failure  to  satisfy  a  storage  allocation  request 
will  result  in  an  overflow  condition  in  the  PE(s) 
which  failed. 

b)  FREEPEB  (<arithmetic  expression>«<confined  pointer  expression>) 
Type  -  None. 

Action  -  Frees  a  block  of  words  at  the  location 
specified  by  the  pointer  expression  in  all  enabled  PE's. 

c)  GETCUB  (<arithmetic  expression>) 
Type  -  CU  non- confined  pointer. 

Action  -  Causes  allocation  of  a  single  block  of 
size  specified  by  the  arithmetic  expression.   Returns 
a  single  (non-confined)  pointer  to  this  block.  Failure 
to  find  storage  will  result  in  a  system  interrupt. 

d)  FREECUB  (<arithmetic  expression>.<CU  non- confined  pointer 

express ion>) 
Type  -  None. 
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Action  -  Frees  a  single  block  of  storage  at 
the  location  specified  by  the  pointer. 

2.9*3  Special  Functions 

A  number  of  special  functions  "will  allow  the  programmer  to  make 
use  of  special  ILLIAC  IV  hardware  features.  These  "will  be  announced  as 
they  become  ready.   Some  of  those  which  have  a  high  priority  are  listed 
below. 

ROTATE 

SHIFT 

SHIFTO 

SHIFTS 

EDIT 


3.   FORMAL  SYNTAX 

This  chapter  contains  the  formal  definition  of  GLYPNIR  I.  This 
definition  will  be  presented  through  BNF  productions.  Many  of  the  non- 
terminals which  appear  will  be  qualified  by  footnotes  which  will  affect  a 
restriction  on  the  type  of  the  entity  represented  by  the  non-terminal. 

1.  <program>  ::=  <unlabelled  block> 

2.  <unlabelled  block>  ::=  BEGIN  declaration  part> 

<statement  list>  END 
3«  <declaration  part>  ::=  <declaration>  ; 

<declaration  part>  <declaration>  ; 
<empty> 
h.     <declaration>  ::=  <register  declaration>  | 

<field  declaration>  | 
<label  declaration>  | 
<subroutine  declaration> 
5«  <register  declaration>  ::=  <type>  REGISTER   <identifier>  | 

<type>  <identif ier>  | 
<register  declaration>  ,   <identifier> 
6.   <type>  ::=  CU  REAL  |  CREAL* 

CU  INTEGER  |  CINT*   | 
CU  ALPHA  I  CALPHA* 


The  word  REGISTER  is  optional,  and  is  included  only  to  improve 
the  error  recovery  abilities  of  the  compiler. 

Optional  abbreviation  for  the  preceding  sequence. 
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CU  NON  CONFINED  POINTER  |  CNPOINT+  | 

PE  REAL  |  PREAL+  | 

PE  INTEGER  |  PINT1"  | 

PE  ALPHA.  |  PALPHAf  | 

PE  CONFINED  POINTER  |  PCPOINT+  | 

BOOLEAN 

7.  <field  declaration>  ::  =  <field  type>  FIELD  <field  specif iciation> 

<field  declaration>,<field  specification> 

8 .  <f ield  type>  : : =  POINT  | 

NPOINT  | 
INTEGER  | 
REAL  | 
ALPHA  | 
9-  <field  specif ication>  : :  = 

<identifier>  [<depth>,<first  bit^lengthX]*  | 
<identifier>  [<depth>,FULL]*   | 
<identifier>  [<depth>, INNER]*   | 
<identifier>  [<depth>,  OUTER]*   | 

10.  <depth>  : :=  <integer> 

11.  <first  bit>  ::  =  <integer> 

12.  <length>  : :  =  <integer> 


t 

Optional  abbreviation  for  the  preceding  sequence. 

For  use  with  REAL  fields  only. 
*Tor  use  with  POINT,  NPOINT,  INTEGER,  or  ALPHA  fields  only. 


Certain  restrictions  are  placed  on  the  length  of  fields  as  noted 
in  Table  5«   In  addition,  no  field  may  cross  a  word  boundary.   See  also 
Section  2.1  of  Chapter  2. 

TABLE  5 
RESTRICTIONS  ON  FIELD  LENGTHS 


ALPHA 

Only  kQ   bits  are  significant  in  arithmetic  operations 

INTEGER 

Only  U8  bits  are  significant  in  arithmetic  operations 

REAL 

See  Section  2.1  of  Chapter  2 

POINT 

<length>  greater  than  or  equal  to  l6 

NPOINT 

<length>  greater  than  or  equal  to  2k 

13.  <label  declaration>  ::=  LABEL  <identifier>  | 

<label  declaration>,<identifier> 

See  also  Section  2.7  of  Chapter  2. 
1*+.  <subroutine  declaration>  ::  = 

SUBROUTINE  Subroutine  identified  <formal  parameter  part>  ; 

<subroutine  body>  | 
<type>  SUBROUTINE  <subroutine  identified  <formal  parameter  part>; 
<subroutine  body> 

15.  <subroutine  body>  ::=  <unlabelled  statement> 

16.  <subroutine  identifier>  ::=  <identifier> 
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17.  <formal  parameter  part>  : := 

(<formal  parameter  specification  list>) 
<empty> 

18.  <formal  parameter  specification  list>  : := 

<formal  parameter  specification>  | 
<formal  parameter  specification  list>  , 

<formal  parameter  specification> 
19«  <formal  parameter  specification>  ::  = 
<type>  <register  identifier>  | 
<type>  OUT  <register  identifier> 

20.  <subroutine  call>  : := 

<sub routine  identifier>  <actual  parameter  part> 

21.  <actual  parameter  part>  : :- 

(<actual  parameter  list>) 
<empty> 

22.  <actual  parameter  list>  : := 

<actual  parameter>  | 

<actual  parameter  list>,<actual  parameter> 

23.  <actual  parameter>  : := 

<register  identifier>  | 
<expression> 
<empty> 
2k.     <statement  list>  ::=  <statement>  | 

<statement  list>;<statement> 
25.  <statement>  : :=  <unlabelled  statement>  | 

<label>  :  <statement> 
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26.  <label>  ::=  <identifier>+ 

27 •  <unlabelled  statement>  ::=  <assignment  statement>  | 

<if  statement>  | 

<for  statement>  | 

<subroutine  statement>  | 

<unlabelled  block>  | 

<empty> 

28.  <assignment  statement>  ::=  <fcd>   <left  arrow>  <expression>* 

<fcd>   <left  arrow>  [<routing  index>] 
<expression> 

29.  <Left  arrcw>  :  :=  *-  |  :  = 

30.  <routing  index>  ::=  <arithmetic  expression> 

31.  <fcd>  ::=  <identifier>++    | 

<function  designator>  | 
<fcd>.<identifier>  | 
<fcd>.[<pointer  index>]  <identifier> 

32.  <function  designator>  : :  =  <subroutine  call> 
33*  <pointer  index>  ::=  <integer>  ] 

<identifier>** 


Declared  label.   See  Section  2.7  of  Chapter  2. 
*See  Table  3,  Section  2.k   of  Chapter  2. 
This  FCD  may  not  begin  with  a  function  designator. 
Register  identifier. 
** Register  identifier,  type  REAL,  INTEGER,  or  ALPHA., 


58 


3^.  <expression>  : :=  <Boolean  expression>  | 

<arithmetic  expression>  | 
<pointer  expression> 
35*  <Boolean  expression>  : :=  <implication>  | 

<Boolean  expression>  EQV  <implication> 
36.  <implication>  :  :  =  <Boolean  term>  | 

<implication>  IMP  <Boolean  terni> 
37*  <Boolean  term>  : :=  <Boolean  factor>  | 

<Boolean  term>  OR  <Boolean  factor> 
38.  <Boolean  factor>  ::=  <Boolean  secondary>  | 

<Boolean  factor>  AND  <Boolean  secondary> 
39*  <Boolean  secondary>  : :  =  <Boolean  primary>  | 

NOT  <Boolean  primary> 
kO*     <Boolean  primary>  : :=  <Boolean  register  identifier>  | 

<Boolean  function  designator>  | 
<logical  value>  | 
(<Boolean  expression>)  | 
<relation> 
kl.     <logical  value>  ::=  BOOLEAN  (<number>)  | 

TRUE  I  FALSE 
TRUE  and  FALSE  are  equivalent  to  1777777777777777777777(8)  and 
0000000000000000000000 (8 ) ,    r e spe c t ively . 

k2.     <relation>  : :=  <aritnmetic  express ion>  <relational  operator> 

<arithmetic  expression>  | 
<pointer  expression>  <relational  operator> 
<pointer  expression> 


43.  <relational  operator>  ::-   LSS   < 

LEQ,  |  < 
EQJ,  |  = 
NEQ  |  / 
GEQ,  |  > 
GTR  |  > 
kh.     <arithmetic  expression>  :  :=  <term>  | 

<adding  operator>  <term>  | 
<arithmetic  expression>  <adding  operator> 
<term> 
h*=>.     <term>  : :=  <factor>  | 

<term>  Multiplying  operator>  <factor> 
k6.     <factor>  ::=  <primary> 
h'J .     <primary>  : :=  <number>  | 

<fcd>+   I 

<alphameric  expression>  [ 
(<arithmetic  expression>) 
k&.     <adding  operator>  :  :=  +  |  - 
^9*  Multiplying  operator>  ::=  x  |  /   DIV 

Arithmetic  operations  are  performed  using  48-bit,  rounded 
normalized  or  ^B-bit  rounded,  fixed  point  arithmetic.  The  DIV  operation 
is  valid  only  when  both  operands  are  of  type  integer. 


Must  have  an  arithmetic  type.   See  Section  2. 3*2  of  Chapter  2. 
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50.  <alphameric  expression>  : :=  <alphameric  secondary>  | 

<alphameric  expression> 

<alphameric  operator> 
<alphameric  secondary> 
51*  <alphameric  secondary>  : :=  <alphameric  primary>  I 

COMP  <alphameric  primary> 
52.  <alphameric  primary>  ::-   <string>  | 

<fcd>f   | 

(<alphameric  expression>) 
53«  <alphameric  operator>  :  :=  WAND  |j  WOR  |  EOR  |  NOR  |  NAND  | 

WEQV  |  WIMP  |  ADB  |  SBB  |  ADD  |  SUB 
5^.  <pointer  expression>  ::=  <fcd> 

55*  <if  statement>  :  :=  IF  <Boolean  expression>  THEN  <statement>  | 

IF  <Boolean  expression>  THEN  <statement> 
ELSE  <statement> 
See  Section  2.5  of  Chapter  2. 
56.  <for  statement>  : :=  FOR  <identifier>  <left  arrow> 

<arithmetic  expression> 
STEP  <arithmetic  expression> 
UNTIL  <arithmetic  expression> 
DO  <unlabelled  statement>  | 
FOR  ALL  <Boolean  expression> 


Type  must  be  alphameric. 
Must  be  of  type  pointer. 
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DO  <unlabelled  statement> 
FOR  ANY  <Boolean  expression> 
DO  <unlabelled  statement> 
See  Section  2.6  of  Chapter  2. 

57.  <go  to  statement>  :  :  =  GO  TO  <identifier>+ 

58.  <subroutine  statement>  : :=  <subroutine  call> 


f Declared  label.   See  Section  2.7  of  Chapter  2, 
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k.      EXAMPLES 

This  chapter  is  devoted  to  examples.   Some  of  these  examples 
have  "been  taken  from  proposed  applications  areas,  others  are.  purely  examples. 
All  of  the  example  codes  have  been  syntax  checked  "by  the  Version  I  compiler. 
In  addition,  the  ILLIAC  IV  assembly  code  generated  by  the  compiler  has  "been 
accepted  by  the  assembler  with  a  few  exceptions  caused  by  recent  modifica- 
tion to  assembly  code  format.   However,  none  of  these  examples  has  been 
simulated. 

4.1  Matrix  Addition 

The  first  example  (Figure  18)  illustrates  a  very  simple  subroutine 
which  adds  two  matrices.   Suppose  we  had  two  n  x  m  matrices  which  were 
stored  "straight".   That  is,  the  elements  of  each  matrix  would  be  stored 
as  shown  in  Figure  19*  Notice  that  the  rows  of  the  matrix  are  "wrapped" 
around  and  end  in  the  i-th  PE  where  i  =  m  -  Gh   x  ((m-l)DIV  6*0-1. 

An  example  of  how  the  subroutine  MATRIXADD  might  be  used  is 
shown  in  the  code  sequence  of  Figure  18.   Here  we  assume  that  two  n  X  m 
arrays  exist  and  are  referenced  by  the  PE  pointer  registers  A  and  B.  A 
pointer  to  the  resultant  matrix  will  be  placed  in  the  pointer  register  C 
Notice  the  use  of  the  special  pseudo  register  PEN  at  lines  2400,  2500. 
This  is  a  PE  integer  register  supplied  by  the  system  and  pre- initialized 
with  the  number  of  each  respective  PE.  Thus,  the  PEN  register  in  PE 
contains  0,  etc. 
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Figure  19*  Matrix  storage  for  example  1. 
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Figure  20.   Linked  list  of  point  vectors 
for  a  graphics  application. 
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Figure  21.   Storage  of  the  rotation  matrix  for  example  2. 
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k.2     A  Graphics  Application 

This  problem,  greatly  simplified,  is  as  follows.  We  have  in 
each  PE  a  linked  list  of  points  which  define  a  subfigure.  A  typical  list 
is  shown  in  Figure  20.  Each  point  is  represented  as  a  set  of  k   homogeneous 
coordinates,  or  more  simply,  each  point  is  represented  by  a  vector.  The 
problem  is  to  multiply  each  point  vector  of  each  subfigure  in  each  PE  by 
a  single  h   x  h   "rotation"  matrix  and  thus  affect  a  rotation  of  all  the 
subfigures.  This  is  done  by  the  procedure  of  Figure  23*  The  single  k   x  h 
rotation  matrix  is  stored  in  a  l6-word  data  block  as  shown  in  Figure  21. 

Notice  that  the  new  values  for  each  point  vector  are  stored  in 
a  new  data  block.  Then,  instead  of  copying  these  values  into  the  old  data 
block,  the  new  block  is  linked  into  the  list  and  the  old  block  is  discarded. 
(This  is  not  very  smart  in  this  case,  but  it  is  a  useful  technique  to  keep 
in  mind.)  This  relinking  is  illustrated  in  Figure  22  where  the  dotted 
lines  represent  new  pointer  values. 

The  field  ENDF  [0,0,32]  is  used  to  mark  the  end  of  the  list  of 
point  vectors  in  each  PE.  Thus,  the  outermost  <for  statement>  in  the  body 
of  the  subroutine  ROTATE  will  cause  PE's  which  have  reached  the  end  of 
their  lists  to  be  turned  off.  When  all  PE's  have  reached  the  end  of  their 
lists,  then  the  (compound)  statement  following  the  outermost  <for  clause> 
(line  1600)  will  be  skipped  and  control  will  exit  the  subroutine. 

Also  notice  the  use  of  the  field  PNTRS  [0,32,32]  (line  2900) 
which  is  used  to  reference  both  pointer  fields  A[0,32,l6]  and  B[0,U8,l6]. 
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k.3     A  Sorting  Problem 

The  next  example  (Figure  25)  is  a  subroutine  which  bubble  sorts 
128  values  (in  one  quadrant).  The  subroutine  could  easily  be  extended  to 
sort  any  number  of  values.  Figure  2k  illustrates  the  algorithm  (assuming 
only  h   PE's  in  a  quadrant). 

The  principal  thing  to  be  noticed  about  this  program  is  the  use 
of  the  assignment  statement  with  routing  index  (lines  2000,  36OO) .  The 
assignment  statement  at  line  2000  causes  the  low  value  in  each  PE  to  be 
replaced  by  the  high  value  from  the  PE's  to  the  left. 

Figure  26  shows  another  listing  of  this  program  along  with  a 
listing  of  the  code  generated  by  the  compiler. 

k.k     Another  Sorting  Program 

The  program  shown  in  Figure  27  is  a  different  coding  of  example 
3.   It  is  included  here  only  to  illustrate  the  availability  of  special 
hardware  access  features  which  will  be  announced  in  a  later  document. 
Figure  28  is  a  listing  of  the  code  generated  from  this  program. 
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Figure  24.   Illustration  of  a  sorting  algorithm. 
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«HRIMT  OOOOOlbO 

»**  thjs  fHf  upnAiiri  1/31/  *9  1900  1 AwRiF  00000200 

<UNI  ABEI  LFD  HLO«"K>  ii«  OOOOO30O 

Bf.IN  PS13  <8lnf.''  TATL>;  00000400 

<BLO<"K  T*IL>  1 1  ■  00000^00 

[[ <STATFMFNT>  psH  /  <nFCLARATION>  #512/  <FKR0R1>  ]t  00000600 

tfl  r<STATrMENT>  PS**  /  <OfCLARATION>  »S12  /  <ErROR 1 >  ]  I  J  * U        00000700 

I    *FMD  eSIS  /  <LRHnh3>  <PlOCK  TAIL>)J  00000600 

<nFrLAR8TTUN>«  «e  00000900 

[POINT  PS1?0  /INTEr,ERPM21/ALPHA#S122/REAL»Sl23  /  00001000 

NPUlNT^«;12A/cnNFlNEr  PO,InTEH  pSl?0/  OOOOUOO 

NflN  CONFINED  PCITNTEP  0S1  24  /HORl  70NT  A|_#S1  25  /                   00001200 

<ANy>  AHFAn  Fl^Ln  *S5  ]  00001300 

FIFLDPS119  00001400 

Ll^Tr [<*!># [<*N>,<*N>,«*N>#]pSl42]/  00001500 

[<*I>fl<*N>#MILL#T#SU31/  00001600 

[<*T>f[<»N>,lMNFR#)*sU4]/  00001 7OO 

[<♦ I >i[<*N>»UlirFR*)0S 145]]  SEPARATOR*/  00001600 

[<TVpf>  /  <*NY>  BUT  K^GTSTEr  BUT*J  PUT  «ENO  00001900 

AHEAD  REGISTER   *S3l  00002000 

t  [REf,IsTERH<*I>#sl4l[  ,[<*T>?sl«0]]*]/  00002100 

LAPEl  <*I>»S148l#[<*I>»S149]]*  /  00002200 

<SMBROuTINf  Df CLAPAT'Om>»  00002300 

<SUBROUTINE  DECLARATION^1*  00002400 

f[<TYpE>  /<ANY>  HUT  SURRnuTlNf  BUT  PROCEnuRE  BUT  *l  BUT  f^ND         OOOO25OO 

AHEAD  SUBROUTINE  I><l4  ]&  00002600 

rSUBROUTINE  /  PRnCFDUKE  »S30 1  #S35)  <*!>  #S3'  00002700 

r[<FfiRMAL  PARAMETER  PART>  J  *#  l)#S36  00002800 

<UNLABFLLED  ST ATEMFNT>#S37  I  00002*00 
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<rnoMAi    pak*mPtfh  p*kt > i t ■  00003000 

flLW     [<TYPF>     [flUTJI     <*T>     »#S3?    /  00003JOO 

LISTr<AMY>    f-uT     .     RUT  )    BUT     IIICLOSE    »S3*]    SEPARATOR    »/                          O0003?00 

[<anv>  put   )   put   ffi*»S331  00003300 

f)/<  >  AHEAD  *>  "S1*  ]»  00003*00 

<TVPF>,'«  00003500 

CN°P!NTPSl?6/  00003*00 

*     PNPOJNT0$1?7/  00003700 

PCPni^Tusl'tt/  00003800 

CRrAl>S1?9/  00003900 

HRr4LPSl3n/  00004000 

CI»'T*>S131/  00004100 

pIMTpSU?/  00004200 

CAI PHAJS13''  00004300 

pAI phA^Si 34/  00004400 

BCIHLEAigpsnb/  00004500 

Cu  NP.N  c^NrlNEo  pOTNTfo  $Sl?6/                                      00004600 

CU  REAL  #S129/  00004700 

CU  INTEGER  (»sl  31  /  00004800 

CU  ALPHA  0*133/  00004900 

Pf  CnNElNEn  POINTER  #$128/  00005000 

PE  RFAL  »S130/  00005100 

pE  INTEGER  *S132/  00005200 

PE  ALPHA  M134.J  00005300 

<STATEMrNT>ns  00005400 

t<*T>  I  NOT  ■  fSl**1*  <HNLARELLEO  STATEMENT^  00005500 

<IINl  AbELLED  STATEmENT>h=  00005600 

ASSIGNMENT  STATfcMEMT>/  00005700 

<E0»  STATpMFNT>/  00005800 
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<lF  sTATFMEkil>/  0000S900 

<XSuHKDUTlMt  STATtMENT>/  00006000 

<UMAPfrLlfD  bL0CK>/  00006100 

<(;n  m  stattmEM>j  00006200 

<FOR  ST  ATFMfNT>t  J=  0000*100 

FOR  [f  ANY/AI  LKPuniFAN  rXHRFSSlON>  DO  0S23  00006400 

[r<*l>i  NHT  =  PSfcl*  <mmlA«PlLEO  STAtEmFNT>»]  *S24  /  00006500 

FOR  f  00006600 

LlSTt<*I>]  «;fpApATt)R  [,  »[<*N>S]  0S98  /  .  lf<*I>  *]  #s98  /.]  OP^N   00006700 

r(»r/cnoE  31H*[[<ANY>  BUT  t]  BUT  STEP  1  *t  IPS  1 1  Ml  <F  *PRESS  ION>  00006800 

esV<9  »S'9  ]  00006900 

STEP  r<ARTTHMFUC  E*PRFSSION>  AHEAD  UNTIL  /  00007000 

r<«NY>  HUT  uNTTl  BUT  fl  BUT  END  RUT  00  BUT  B^GlNl*  #S*  ]  00007100 

IJMTTL  [<ARITHMtTlr  EXPRESSI0N>  AHFAO  DO  /  00007200 

r<ANY>  HUT  DO  FUT  »t    BUT  REGlN  BUT  EnDI*  l»S*]  00007300 

On  *S?0  [r<»I>«  NOT  s  *S8  ]*  <UNLABELLED  <TATEMENT>»]  PS21J  00007400 

<IF  STATEMENT>l f*  0000^500 

IF  <BOOLEAN  EXPRLSSION>  00007600 

THEN  HS?*  t<STATFMENT>»]  *S26  00007700 

f[ELSF  <«;TATFMFNT>»]«  ]  PS27  1  00007800 

<as<;ignment  STATLMFMT>»  I*  0000^900 

LIST[<*I>]  SEPARATOR  [.  #C«*N>#]  *S98  /  .  «[<•!>  #]  #S98  /.]  OPEN  00008000 

r[|«/COOE  31U«[<APITHmCt!c  ExprEssION>*]0S97]»j<ExprEs$ION>   00008100 

PS99'  00008200 

<XSUBRnUTINF  STATEMFNT>  ii.  00008300 

<*I>(  PS40  I  1ST  I  00008400 

<*I>  AhEAq  ,  pTi»l  /  00008500 

<M>  AHEAD  >  *»T<*1  /  00008600 

<PAREyHRfsSION>  M*2  /  00008700 
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t<  >1  »hEAd  ,  pS43  /  OOOOAfcOO 

r<  >i  aheap  '  f»s«3  /  oooo«<?oo 

<ERRnRS>  j  poouqooo 

SEPARATOR*  OPEN  O0009100 

[)  /  <E»RORa>  ]   *46  /  00009200 

<*I>   »«A  f        XNOTE  <»«*>  IS  THE  SAME  AS  <*S«A>.  O000<}300 

<FRP0R4>nr  00009400 

[<ANY>  BUT  II  RUT  )]*C)1I  t»S45  J  O0009410 

<ER»0R5>II«  00009420 

list[<any>  but  »  but  )  but  #1]  close  *s44  i  00009430 

junction  oesigmator>  m*  00009500 

Ittfltt         <*I>    WOT    (     MM    *S«6    ?S39    /  00009600 

<XSU"ROUTINE    STAU*ENT>    «S39»  O0009700 

00009BOO 

<pAREXP*ESSlON>tl«  00009900 

<ARTTHMETIC  EXPRESSTON>   NOT  t»  /  LEO  /  LSS  /  EOL  /  00010000 

GF<5    /    GTR    /    sr"    /#/#>/#</S/fel/  00010100 

<B0OLEAN    EXPRESSION/  00010200 

<PO!NTER    EXPRESSION    \  00010300 

<FCn>tl«  00010400 

[<•!>    NOT    (       ?T80    t»S50       /    <FUNCTlON    OESIGNATOR>]  00010500 

t.<M>       *S*7    /  00010600 

.    #t<*l>t]<*I>       »S«7    /  00010700 

.    #[<*N>«]    <*!>      t»s«7 3*1  00010600 

<G0    TO    STATEMFNT>««,  00010900 

GO   TO   <*I>   »St*7    J  ooonooo 

<E*PRESMON>« 's  O0011100 

<ARTTHMFTIC    EXPRESSION>      NOT    T*    /    LEO    /    LSS    /    EftL    /  OOOHPoo 

GE«    /    GTR    /    NFU    /#/#>/#</</>]/  00011300 
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<Bnn|_FAN    FXPKESSIDNW  0001KOO 

00011SOO 

<P(1TNTER  FXpWESSiriN>  /  00011600 

<ER*0R2>J  00011700 

<ARTTHMfTlC  rxp«»ESS!UM>H«  00011600 

tr*/"l  <TERM>  *s^  /  <TFRM>]  00011900 

[[♦/-I  <TE"M>  PMOM*  t  00012000 

<TEBM>ii»  00012100 

<SPFCIAL  TEPM>   [T*/  #/1  <SPFCIAL  TFRM>  9S10UM  00017200 

<SPFMAL  TFkM>U  =  00012300 

<PRlMARY>[nitf  <PR1MARY>  §S101]*»  00012400 

00012500 

<PRTMARY>n,  00012600 

<FCn>0TlAO/  00012^00 

[{[^ARITHMETIC  E*PfcFbSION>  AHFAO  )  00012800 

/T[<ANY>  BUT  )  RUT  t\    BUT  RFGIN  BUT  ENOJ*  ^S?  J 1  [  )/<ERROR?> )  00012900 

•  S100  1/  00013000 

<A[_PHaMErTc  ExPrEssTun>/  00013100 

<*N>  0S71  *  00013200 

<ALPHAMrRIC  ExPrEsSIUN>ii»  00013300 

<ALPHAMERIC  PRIMARY>  00013400 

[[WANO/WOR/hPfiV/WlMP/EoR/NOR/NANO/AOB/SBB/AOO/SUB]  00013500 

<ALPHAMr«IC  PRJMARY>  9S90  J*J  00013600 

00013700 

<ALPHAMFRIC  PRIHARY>|t*  00013800 

(<AI  PHAMERK  EXPRESSION  )f>S100  /  00013900 

COMP  <ALPHAMER!C  PHIMARY>  9S91  /  00014000 

00014100 

<FCn>nTl62J  00014200 
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<enniEAN  r x^wf sston>   ii«  0001*300 

<1MPLTC*T10M>  r  LOV  <IMPLICATI0N>  *M04l*  CI  OST  #S103j  0001*400 

O0O14500 

<  I  MP(  lCATinN>l  le  00014600 

<H0nirAN  TE«M>  f  !  ►  P  <BPOLEAN  TFRM>  *S105)*I  OOOU'OO 

00014800 

<Hnni  EAN  TFR*>||3  00014900 

<HC10LFAN  FACTOR>  fOH  BOOLEAN  FACTOR>  *S106l*J  O0015000 

00015100 

<HOni  FAN  FACrnH>M»  O0015200 

<801LFAn  SFCONniKY>  [ANO  <BOntF;AN  SFCONOARY>  »S107]*J  00015300 

00015400 

<Bnm  EAN  SFCnNDA»Y>U«  00015500 

UNflT     <POn|_EAN  PKTMAKV>  0S1O'/  00015600 

<H0OLEAN  PHTMARY>  J  00015700 

<B00l  EAN  PRlMARY>M«  0001^^00 

(<BnoLEAN  EYP«FSSIC)N>  )«S100   /  00015900 

<REi  ATlnN>/  0001«000 

<FC1>I»T161/  00016100 

<LD',,lCAL  VAluE>   I  00016200 

<RELATI0m>i«3  00016300 

<ARTTHMETlC  ExPRtSSTUN>  <RELATlONAL  OPERATOR>  00016400 

<ARITHMETIC  EXPRESSION^  PS117  /  00016500 

<POTNTER  EXPRESSlON>  <RrLATlONAL  OPERATOR>  00016600 

<POINTFR  FXPRlSS!ON>  #S1 1 7  >  00016700 

<RFLATlONAL  npERATOR>  its  00016800 

LSS  Mill  /COOF.  30/  O00U900 

LEo  nsn2  /cOoE  47/  00017000 

eol  »sii3  /■/  oooi7ioo 
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nfo  RS116  'cum.   tQ/ 

r.Eo    «$ll'i    /cflor    is/ 
gtk  asiib  /run*    14» 

<LnGTCAl     vAl.l)f>«»  = 
TWljr    »S9A/ 

BUDI  EAN(<»RTTHMFTK    t*P»E SSI  ON* >    *S110' 
<p0TNTFp    FxpRf  S<;  ION>  I  t* 

<FCn>(»Tlft3    *S10?J 


<FRPnRl>     I  la 

[<A*'Y>  RUT  »j  Bl)T  BFlilN  HUT  END] 
[<AMY>  RUT  t;  BUT  BEblN  BUT  END]*  0S2J 

<ERRnR2>  i  i» 

kany>  but  ♦  but  -  "ut  *  But  */   But  oiv 

but  )  but  *»  hut  »  rut  fnd  but  begin]* 

0S?  tt*  /-/*/»/  /  oivj  <arithmetic  e*p»ession>jij 

<ERR"R3>i  l  = 

[<ANY>  BUT  #J  Bi)T  BFlilN  BUT  FND]*  #$2J 

END 


00017200 

0001/300 

00017400 
00017500 

00017600 
00017700 

00017800 
OOOI79OO 

00018000 

00018100 

00018200 

00018300 

0001*400 
00018500 

000l8600 
00018700 
00018800 
00018900 
00019000 
00019100 
0001*200 
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APPENDIX  B 
RESERVED  WORDS 
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Class  A  Reserved  Words 

Table  B-l  lists  the  reserved  words  of  GLYPNIR.   If.  the  RSWD 
option  is  not  used  (see  the  GLYPNIR  operation  manual),  then  these  words 
must  be  prefixed  by  a  "#"  character. 


TABLE  B-l 
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ADB 

ADD 

ALL 

ALPHA 

AND 

ANY 

AS 

BEGIN 

BOOLEAN 

CALFHA 

CINT 

CNPOINT 

COMP 

CONFINED 

CREAL 

CU 

DIV 

DO 

ELSE 

EOJL 

EQV 

EOR 

END 

FALSE 


FIELD 

FOR 

FULL 

GEQ 

GO 

GTR 

HORIZONTAL 

IF 

IMP 

INNER 

INTEGER 

LABEL 

LEQ 

LSS 

NAND 

NEQ 

NON 

NOR 

NOT 

NPOINT 

OR 

OUT 

OUTER 

PALPHA 


PCPOINT 

PE 

PINT 

PNPOINT 

POINT 

POINTER 

PREAL 

PROCEDURE 

REAL 

REGISTER 

REPEAT 

SBB 

STEP 

SUB 

SUBROUTINE 

THEN 

TO 

TRUE 

UNTIL 

WAND 

WEQV 

WIMP 

WOR 
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Class  B  Reserved  Words 

Table  B-2  lists  the  class  B  reserved  words.  These  are  predefined 
register  identifiers  and  are  not  preceded  "by  a  "#"  regardless  of  whether 
or  not  the  RSWD  option  is  used.  Each  of  these  identifiers  has  a  special 
meaning  in  that  they  refer  to  actual  ILLIAC  IV  hardware  registers.   However, 
the  programmer  may  redefine  these  identifiers  if  he  does  not  want  or  need 
to  access  hardware  registers. 
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TABLE  B-2 


CARO  RGC  RGH 

CAR1  RGD  RGI 

CAR2  RGE  RGJ 

CAR3  RGE1  RGR 

MODE  RGF  RGS 

RGA  RGF1  RGX 

RGB  RGG 
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Class  C  Reserved  Words 

These  are  predeclared  GLYPNIR  identifiers.  They  may  be 
redefined  by  the  programmer. 


TABLE  B-3 
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ABS 

FREEPEB 

GETPEBL 

CSTK 

FREEPEBL 

PEN 

ENTIER 

GETCUB 

PSTK 

FREECUB 

GETHB 

SIGN 

FREEHB 

GETPEB 

UNCLASSIFIED 
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